home *** CD-ROM | disk | FTP | other *** search
/ Graphics Plus / Graphics Plus.iso / amiga / modelers / chmsthtc / chmsthtc.lzh / Chemesthetics / Source / SrcReadMe! < prev   
Encoding:
Text File  |  1991-11-25  |  7.8 KB  |  176 lines

  1. Hints for programmers: (updated 22-Oct-91)
  2. ==========================================
  3.  
  4. !IMPORTANT NOTE FIRST!
  5. ----------------------
  6.  
  7. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  8. Since V2.07 I supply the lmkfile I USE (before I supplied one, I just built
  9. for the distribution disk), because I don't want to hassle around with two
  10. different lmkfiles. I too often forget to adapt the second one after making
  11. changes to the first. The big differences between those two was: in the
  12. lmkfile I REALLY used, I use my own linker library (ex.lib) for certain
  13. small routines (Ellipse,Line...); in the lmkfile I SUPPLIED these routines
  14. were located in an extra file (extra.c). I did this to give owners of an
  15. Aztec-C-Compiler a chance to recompile the files. Meanwhile I use so many
  16. SAS/Lattice C specific things (e.g. __chip keywords), that I don't think
  17. any Aztec user will have much use of the source files. So to make life a
  18. bit easier for the SAS/Lattice owners (and for me too, of course), I now
  19. just supply the really used lmkfile AND the lib (ex.lib). I didn't have
  20. time to document it, yet, as soon as I have, I will distribute it on PD.
  21. All desperate Aztec users, who for some reason want to recompile the
  22. sources with their compiler can write in to me (i.e. send me a disk) and I
  23. will return the full source code (incl. the ex.lib source).
  24. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  25.  
  26.  
  27. Now the other interesting things:
  28. --------------------------------
  29.  
  30. First, all source files have been compressed into an archive (Source.LZH)
  31. using Lharc V1.30 (AmigaLibDisk 404). I have included Lharc V1.30 on my
  32. distribution disk. However I don't know if all PD-distributors leave it
  33. there, so you may be have to get elsewhere. All other (older) versions of
  34. Lharc should also work, though I have not tested them.
  35.  
  36. All source files have been compiled with the SAS/Lattice C 5.10a Compiler.
  37. See below for problems concerning the optimizer! All files use
  38. 32-bit-integer variables so I hope there is no problem in this aspect.
  39.  
  40. Besides source-file-specific headerfiles (*.h) which are located in the
  41. source root directory (on the same level as the *.c files they belong to),
  42. I provide all the needed header files for the req.library, the arp.library
  43. and the iff-saver (ilbmw.c). Because I now (since V2.07) provide
  44. also the source code of 'ConvM3D', I now store all source files with their
  45. pathnames. This will lead to problems during the compile process,
  46. because it is very unlikely that you use the same directory
  47. structure as I do. This causes problems when you compile certain files (for
  48. example ilbmw.c), because the include files are supposed to be located in a
  49. subdirectory (in this case iff/). You may either change the #include lines
  50. in the problematic files or you may create a subdirectory INCLUDE below the
  51. source root directory and include the -i option in the lmkfile at the
  52. CFLAGS. If you do so I recommend to organize the files as follows:
  53.  
  54. source/
  55.   *.c        source-files
  56.   *.h        other header files
  57.   extra.c   has to be moved from pdomain/ to the source root directory!!!
  58.   lmkfile   automatic compilation and linking if you use LMK, has to be
  59.         moveded from pdomain/ to the source root directory!!!
  60.   include/
  61.     clib/
  62.       req_protos.h
  63.     libraries/
  64.       reqbase.h
  65.       arpbase.h
  66.     iff/
  67.       compiler.h
  68.       gio.h
  69.       iff.h
  70.       ilbm.h
  71.       packer.h
  72.     proto/
  73.       arp.h
  74.       mtwx_defs.h
  75.       req.h
  76.     convm3d/
  77.       convm3d.c       main file for ConvM3D
  78.       rev.c          revision code for ConvM3D
  79.       lmkfile          automatic compilation and linking if you use LMK
  80.  
  81. A lmkfile is provided, so Lattice users could simply type LMK and the
  82. compile process will run automatically (see below for the memory problem).
  83.  
  84. **** PROBLEM:
  85. Unlike the old Aztec C Compiler (V3.6a), the SAS/Lattice C Compiler 5.10a
  86. needs a terrible amount of memory during the compilation process. I have
  87. great problems in compiling the main file (chemest.c) even though I've got
  88. 1 MByte RAM. I have to disconnect my external drive and switch off MachIII
  89. even though I place the quad file on my hard disk (-qdh0:). If anybody has
  90. a solution to this, please let me know. It seems to be a problem of the
  91. precompiler, because most of the memory has been eaten up before the real
  92. compilation process is started (I used SnoopDos to check this). What do the
  93. users with just 512 KByte do, Lattice ? It seems impossible to me that they
  94. can compile any program that #includes more than eight files.
  95. I will try to chop the chemest.c into several smaller files and #include
  96. exactly what is needed and won't use a (large) precompiled header file.
  97. Maybe this will do for a while, but this can't be the solution, Lattice. I
  98. hope there will be a solution with the next compiler release.
  99.  
  100.  
  101. I have some problems in writing a convenient message-receiving routine.
  102. Sometimes the GURU will visit you if you select a menu or close a window. I
  103. reduced the frequency of the Guru's appearance by using ARP's
  104. CloseWindowSafely() instead of Intuition's CloseWindow(), but it still
  105. happens sometimes. PLEASE: If anyone has a solution for this please let me
  106. know. I looked thru lots of computer magazines but I didn't find anything
  107. else than my Nachricht() (-> Message) routine.
  108.  
  109. I use my own (well actually it comes from QuickReq.c from AmigaLibDisk457)
  110. _main() routine to get rid of that f***ing console window that is opened by
  111. all files compiled with the Lattice compiler (take that away Lattice, it
  112. must be up to the programmer to include this!). The console window that is
  113. now opened is my own (see OpenRevWin in extra.c) and I need it to display
  114. certain messages.
  115.  
  116. By now I use the following routines outside of AmigaDOS, Intuition etc.:
  117.  
  118. ArpAlloc          arp.library
  119. CloseWindowSafely      arp.library
  120. FileRequester          req.library
  121. SimpleRequest          req.library
  122. TwoGadgetRequest      req.library
  123. SetLocation          req.library
  124. ReadLocation          req.library
  125. SetSize           req.library
  126.  
  127. I do not use the req.library's palette requester because it does not have
  128. all the things a good palette requester has to have. Instead I use Jonathan
  129. Potter's paletterequest(). Thanx Jonathan, it's old, but it's still the
  130. best!
  131.  
  132.  
  133. Do not change rev.c, as it has a special format that is needed by other
  134. files.
  135.  
  136. All source files come with German comments and (partly) German names for
  137. routines and variables. If you would like to know what they mean, well, try
  138. learning German, it's a fascinating language.
  139.  
  140. The newer files are ANSI-C compatible and they are compiled with the -ca
  141. option of the compiler. The current version is a mixture of ANSI and
  142. non-ANSI files, I intend to make ALL files ANSI compatible in the future.
  143.  
  144. I intended to provide a makefile for Aztec C users and to embedd Lattice
  145. specific things in #ifdefs but I didn't have the time yet. If somebody does
  146. this, I would like to get a copy of this. If nobody does I may do it on my
  147. own somewhere in time... Let's wait'n'see!
  148.  
  149.  
  150. Some words about optimization:
  151. ------------------------------
  152.  
  153. Due to my lack of leisure time, I can't optimize the program as much as I
  154. want to, so I handed this over to the global optimzer GO (Option -O) of the
  155. SAS/Lattice C packet. Unfortunately, GO does seem to have some bugs. In the
  156. released version V2.06 the input of data is *NOT* possible, the program
  157. crashes while or before modifying the prop-gadget. While debugging (and for
  158. that removing the -O option), the error didn't occur. Same as with the
  159. palette requester. So I changed the lmkfile so that neither palettereq.c
  160. nor eingabe.c will be optimized. If you use your own lmkfile be aware of
  161. that. DON'T OPTIMIZE palettereq.c AND eingabe.c!!
  162.  
  163.  
  164. Have fun!
  165.  
  166. Joerg
  167.  
  168.  
  169. P.S. None of the files may be touched, changed, deleted or distributed on
  170.      own series of Stefan Ossowski PD-Versand, Rainer Wolf PD-Versand
  171.      (OASE) and Markt & Technik Verlag AG,
  172.  
  173.      Greetinx to Bernstein Softworks (Risk, Dragon Cave) for their RIGHT
  174.      attitude concerning some kind of PD distributors.
  175.  
  176.